This looks good, I'll try and get it reviewed :)

Thanks for sending this, and diving into the export_unity_package script! At a first glance it seems good, but I'll want to spend some time testing it with different install configurations to make sure it doesn't cause any issues, which might take a little bit of time. But I'll try to get to it when I can!

@a-maurice feel free to push any changes or remake this PR as needed :)

Is it possible to get this change in some way without building locally from latest source? We have https://github.com/googlesamples/unity-jar-resolver.git?path=upm added as an dependency in unity per instructions, but this I presume just gets the latest release, which currently doesn't seem to contain this fix. Since the files lives inside the package folder using this method, which we very much prefer from having it live in the Assets/ folder, we can't modify served file locally to fix it manually. As such this issue is preventing any build from succeeding for us in Unity 6.

which we very much prefer from having it live in the Assets/ folder.

I disagree. We definitely don't want it assets folder. It properly belongs in packages since it is external. Downloaded as .unitypackage it makes sense to be in assets folder.

which we very much prefer from having it live in the Assets/ folder.

I disagree. We definitely don't want it assets folder. It properly belongs in packages since it is external. Downloaded as .unitypackage it makes sense to be in assets folder.

That's what I'm saying, English isn't my first language but yes, I want all plugins out of the Asset folder, because we want to disable for example the google play plugin entirely for build targets where it isn't relevant, which is impossible if it's in the Assets folder.

That's what I'm saying, English isn't my first language but yes, I want all plugins out of the Asset folder, because we want to disable for example the google play plugin entirely for build targets where it isn't relevant, which is impossible if it's in the Assets folder.

Then just unzip the .tar packages and do local embed. But tbh the way it is currently setup is IMHO the best and correct way to package this type of asset. That isn't gonna ever change.

Thanks for sending this, and diving into the export_unity_package script! At a first glance it seems good, but I'll want to spend some time testing it with different install configurations to make sure it doesn't cause any issues, which might take a little bit of time. But I'll try to get to it when I can!

@a-maurice Any news / eta on this?
My specific case with this issue is that when I add the Firebase Cloud Storage tgz (com.google.firebase.storage-12.8.0) using UPM, I get this error. Only a small part of my team builds for ios, so it doesnt make sense to have everyone with the ios module installed. Also, as UPM package I cant remove the Validate Reference options on the IOSResolver, and I also cant add it as .unitypackage, as there are files inside Firebase storage lib that have more then 100mb, which my infra wont allow when commiting.

My only option seems to not use firebase at all and go to AWS and such.

Sorry for the delay in response to this. To follow up, while this approach will generally work at fixing EDM4U's iOS resolver DLL, it inadvertently can cause problems for libraries that (perhaps incorrectly) assume that the iOSResolver dll will always be present, for example, the Firebase Editor dll.

On the positive side, I think I might have a solution that works by changing all the direct dependencies to use reflection instead. Obviously this is a bit more fragile, so I still need to test it thoroughly, but initial testing seems good.

iOSResolver dll will always be present

This will remain true. We only switch the compile symbol and exclude UNITY_IOS from compilation.

Firebase Editor dll

Yes this properly fixes the missing reference in that dll specifically on non-iOS build targets.

I've been using a copy of this fix for ~1 year w/o any problems on iOS, Android, macOS, and Windows standalone builds 😅

iOSResolver dll will always be present

This will remain true. We only switch the compile symbol and exclude UNITY_IOS from compilation.

Firebase Editor dll

Yes this properly fixes the missing reference in that dll specifically on non-iOS build targets.

I've been using a copy of this fix for ~1 year w/o any problems on iOS, Android, macOS, and Windows standalone builds 😅

I'm not surprised it works for you, and a lot of the test cases I tried did work. But at least on my mac, Unity 2021 with iOS support installed, I regularly see this pop up as a logged error, basically whenever the DLL reloads:

FileNotFoundException: Could not load file or assembly 'Google.IOSResolver, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
Firebase.Editor.XcodeProjectPatcher.OnPostprocessAllAssets ...

Admittedly, it isn't a breaking problem, and I can still run/build on the other platforms without issue, so it is technically better, but there isn't a workaround to prevent that log that I could find with this solution, and I'd like to avoid the confusion on that error log if possible.

Hmm, I'll check out the specific build configuration and double check the work then. What is the PostProcessAllAssets trace being called?

Here is the full stack I see:

FileNotFoundException: Could not load file or assembly 'Google.IOSResolver, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
Firebase.Editor.XcodeProjectPatcher.OnPostprocessAllAssets (System.String[] importedAssets, System.String[] deletedAssets, System.String[] movedAssets, System.String[] movedFromPath) (at /Users/runner/work/firebase-unity-sdk/firebase-unity-sdk/editor/app/src/XcodeProjectPatcher.cs:258)
System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <383fd28f951445cc8fd8a4a8bba28de6>:0)
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <383fd28f951445cc8fd8a4a8bba28de6>:0)
System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at <383fd28f951445cc8fd8a4a8bba28de6>:0)
UnityEditor.AssetPostprocessingInternal.InvokeMethod (System.Reflection.MethodInfo method, System.Object[] args) (at /Users/bokken/build/output/unity/unity/Editor/Mono/AssetPostprocessor.cs:1145)
UnityEditor.AssetPostprocessingInternal.PostprocessAllAssets (System.String[] importedAssets, System.String[] addedAssets, System.String[] deletedAssets, System.String[] movedAssets, System.String[] movedFromPathAssets, System.Boolean didDomainReload) (at /Users/bokken/build/output/unity/unity/Editor/Mono/AssetPostprocessor.cs:385)

It is very odd, sometimes it won't show up, other times it will. Generally, the reliable way I'm seeing it is: MacOS, latest Unity 2021.3, with iOS support installed, targeting to build for Android, but with the GoogleServices plist for iOS present. Based on the code comments, it tracks that file because of the settings window regardless of selected platform, which is probably what triggers the iOS Resolver invocation into exception. https://github.com/firebase/firebase-unity-sdk/blob/4d3fcaae4783d6036cd13bccffc80de200e1f4e8/editor/app/src/XcodeProjectPatcher.cs#L256